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PROCEDE D'ACCES AU SERVICE AVEC AUTHENTICATION RAPID E ET 
ANONYMAT REVOCABLE 

DOMAINE TECHNIQUE 

LMnvention concerne le domaine de la securite des acces a des 
5- services, notamment a des ressources informatiques. 

LMnvention a pour objectif general d'offrir un service 
d'authentification forte et anonyme d'utilisateurs et un mecanisme 
rapide et economique de maintien de session d'authentification. 
LMnvention permet, malgre I'anonymat, de responsabiliser les 
10 utilisateurs en offrant aux ressources la possibility de lever I'anonymat 
de Tutilisateur le cas echeant (en cas de litige par exemple). 
APPLICATIONS 

LMnvention peut trouver de nombreuses applications. Celles qui 
seront indlquees par la suite ne doivent pas etre considerees comme ■% 

15 limitatives. ■ ">% 

• ' -¥ 

Les applications majeures de cette invention sont les encheres : .* 

•?* 

electroniques ou les jeux en reseau/communaute. En fait, ^invention est. y 
adaptee en particulier a toute application dont le but est de proposer : I 
une place publique ou plusieurs utilisateurs peuvent se reunir et 

20 echanger tout en gardant leur anonymat. 

LMnvention est particulierement pertinente pour les encheres 
electroniques dont le but est de reproduire le principe de fonctionnement 
des encheres reelles. Les encheres reelles permettent a des personnes, 
reunies dans une meme salle, de faire des offres de maniere anonyme, 

25 Bien que ieur identite reelle ne soit jamais devoilee, les participants ne 
peuvent pas se retracter. La presente invention offre les memes 
proprietes d'authentification anonyme et de non-repudiation. 

Ces memes fonctionnalites peuvent egaiement etre exploitees 
pour des applications de jeux rnulti-acteurs, tels que les jeux de casino, 

30 ou plusieurs personnes se reunissent autour d'une meme table de jeux 
sans se connaitre les uns les autres. Lorsqu'un joueur mise sur un 
numero, il ne peut pas nier avoir mise sur ce numero. La presente 
invention offre ces proprietes : elle garantit Tanonymat des joueurs 
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(I'identite des joueurs n'est pas revelee) tout en les responsabilisant 
(I'identite des joueurs pourra etre revelee si besoin). 

ETAT ACTUEL DES CONNAISSANCES PUBLIEES SUR LE SUJET 
(ART ANTERIEUR LE PLUS PROCHE) - INCONVENIENTS DE LA 
5 TECHNIQUE ANTERIEUR? 

Le but general de Pinvention est de proposer des moyens 
permettant 1) de garantir I'anonymat des clients, 2) de maintenir 
efficacement une session d'authentification et 3) de responsabiliser les 
clients. 

10 Aujourd'hui, un certain nombre de techniques permettent de 

repondre en partie a ces exigences, mais aucune n'offre de solution 

complete a la problematique globale. 

Certaines techniques permettent a un serveur d'authentifier un 

client. Ces techniques sont generalement couplees a un mecanisme 
15 permettant de maintenir une session d'authentification entre I'utilisateur 

et le serveur. 

Les techniques majeures off rant des services d'authentification 
et de maintien de session sont les suivantes : 1) les mots de passe 
jetables, 2) les techniques SSL etTLS et 3) la technique Kerberos. 
20 • Les mots de passe jetables : le principe des mots de passe 

a usage unique - encore appeles mots de passe jetables ou OTP (One- 
Time Password) - consiste a utiliser des mots de passe qui ne peuvent 
etre utilises qu'une seule fois. Meme si le mot de passe est derobe, il 
n'est pas reutilisable. Dans la pratique, ce dispositif prend generalement 
25 la forme d'une cartulette (ex. ActivCard, SecurlD) qui calcule les mots 
de passe que I'utilisateur doit saisir pour s'authentifier. Ce mot de passe 
est ensuite utilise pour calculer une de de session (une cle secrete) 
destinee a garantir la confidentiality et I'integrite des echanges. 

a SSL et TLS : ce sont des techniques qui reposent sur des 
30 certificats et des algorithmes de cryptographie a cles publiques (ou 
asymetriques) pour Pauthentification et des algorithmes de 
cryptographie a cles secretes (ou symetriques) pour le maintien de 
session. Un certificat constitue une carte d'identite numerique. II prend 
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la forme d'un fichier contenant une cle publique et des informations .sur 
son proprietaire. Ces informations sont certifiees (i.e. signees) par une 
autorite de confiance appelee autorite de certification. Typiquement, 
pour authentifier un utilisateur, un serveur iui envoie un challenge (une 
5 valeur numerique aleatoire) que Putilisateur signe avec sa cle privee. La 
cle publique permet au serveur de verifier que Putilisateur possede bien 
la cle privee, le certificat de connaitre I'identite de Putilisateur. En outre, 
cette phase d'authentification permet au client et au serveur de 
s'echanger une cle de session (une cle secrete) qui leur permettra de 
10 garantir la confidentialite et rintegrite de leurs echanges. 

® Kerberos : il s'agit d'un mecanisme de SSO (Single Sign- 
On) permettant a un utilisateur d'acceder a plusieurs ressources sans 
avoir a s'authentifier plusieurs fois. II repose sur des algorithmes de 
cryptographie a cle secrete. Typiquement, pour acceder a un serveur, 
15 Putilisateur s f authentifie aupres d T un distributeur de des ou KDC (Key 
Distribution Center) qui Iui retourne un jeton d'authentification pour ce 
serveur cible, Ce jeton est envoye de maniere transparente au serveur 
cible et Iui permet dMdentifier/authentifier ^utilisateur et de recuperer 
une cl£ de session (une cle secrete) utilisee par le serveur et le client 
20 pour garantir la confidentialite et rintegrite de leurs echanges. 

Les inconvenients majeurs de ces techniques connues sont les 
suivants : 

* Uanonymat des utilisateurs n'est pas preserve : Les 
mecanismes d'authentification proposes par ces techniques sont 
25 destines a verifier Pidentite reelle du client. Cette identite est devoilee 
par le login dans le cas des mots de passe jetables, par le certificat dans 
le cas de TLS et SSL ou par le jeton d'authentification dans le cas de 
Kerberos. 

® La non-repudiation n'est pas garantie : Ces techniques 
30 s'appuient sur des algorithmes de cryptographie a cle secrete pour 
maintenir la session d'authentification et garantir la confidentialite et 
rintegrite des echanges. Ce type d'algorithme cryptographique ne 
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permet pas de garantir la non-repudiation ; Le client peut toujours nier 
avoir envoye un message. 

o Le maintien de la session est couteux : le maintien de la 
session est realise en chiffrant ou en authentifiant les messages que le 
5 client et le serveur s'echangent. Le client doit, en permanence, disposer 
de moyens de calculs pour maintenir la session. 

D'autres techniques offrent des mecanismes d'authentification 
permettant de preserver I'anonymat des utilisateurs. 

L'utilisation d'un pseudonyme est I'approche la plus couramment 
10 utilisee par les serveurs actuellement deployes sur Internet (ex. les sites 
d'encheres electroniques, les sites de jeux). Cette technique repose sur 
un mecanisme d'authentification base sur l'utilisation d'un login (i.e. le 
pseudonyme) et d'un mot de passe. Les utilisateurs s'enregistrent 
generalement aupres du serveur en renseignant un certain nombre 
15 d'informations personnelles et en choisissant un pseudonyme et un mot 
de passe qu'ils devront ensuite presenter pour s'authentifier. Cette 
approche pose un certain nombre de problemes : 

o Probleme d'ergonomie : chaque utilisateur doit 
s'enregistrer aupres de chacun des serveurs en entrant plusieurs fois les 

20 memes informations. 

• Probleme d'anonymat : Les informations personnelles des 
utilisateurs sont stockees sur chaque serveur. L'anonymat d'un 
utilisateur est garanti vis-a-vis des autres utilisateurs mais pas vis-a-vis 
du serveur. L'utilisateur doit done faire totalement confiance a chacun 

25 des fournisseurs de services. 

o Probleme d'identification et de responsabilisation : les 
informations renseignees par I'utilisateur ne sont pas ou peu verifiees. 
L'utilisateur est authentifie mais faiblement. II peut done entrer des 
informations erronees, se falre passer pour quelqu'un d'autre ou 

30 s'enregistrer plusieurs fois en utilisant differents pseudonymes. D'une 
maniere generate, cette approche ne permet pas de responsabiliser 
I'utilisateur puisque le serveur ne peut rien prouver. 
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• Probleme de tragabilite : le serveur peut suivre les activates 
de ses clients et peut ainsi en deduire un profil, information souvent plus 
interessante que IMdentite reelle, Uanonymat n'est done pas 
completement garanti. 
5 Les techniques de signature de groupe voir documents ([1], [2], 

[3] et [4] et utilisees notamment pour les encheres electroniques dans 
Particle [5]) offrent egalement un mecanisme d'authentification 
anonyme. Le principe general consiste, pour un client, a s'inscrire 
aupres d'une autorite de confiance, le gestionnaire du groupe. Les 

10 clients enregistres aupres de cette autorite appartiennent a un meme 
groupe et disposent des moyens necessaires pour signer au nom du 
groupe. Tout serveur dispose des moyens pour verifier une signature. La 
verification d'une signature consiste, en fait, a verifier qu'elle a bien ete 
produite par un membre du groupe ; Elle ne devoiie rien sur le membre 

15 qui I'a produite et ne permet done pas au serveur de connaTtre son 
identite. L'anonymat des clients est done garanti. Un serveur peut, 
neanmoins, interroger le gestionnaire de groupe pour lever Tanonymat 
du signataire. 

Cette technique repond done a la problematique. 

20 d'authentification anonyme. En revanche, elle nMntegre aucun 
mecanisme permettant de maintenir une session d'authentification entre 
un client et un serveur. Le serveur ne peut done pas se "souvenir" de 
Tidentite du client. Pour maintenir Tauthentification, le client doit signer 
chacun des messages quMI transmet au serveur et doit done disposer en 

25 permanence des moyens de calcul necessaires. De plus, les calculs mis 
en ceuvre pour realiser de telles signatures sont assez consequent et ne 
permettent pas une authentification rapide. 
BUT DE ^INVENTION 

Un but de ('invention est de fournir une solution complete a la 
30 problematique d f authentification anonyme et de maintien de session. 
BASE DE ^INVENTION 

Le but pr^cite est atteint dans le cadre de la presente invention 
grace a un procede qui comprend les etapes consistant a : 
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0 identifier et enregistrer un Client et lui fournir des moyens lui 
permettant de s'authentifier aupres d'une Autorite de Certification 
Anonyme, 

i0 authentifier le Client aupres de I' Autorite de Certification Anonyme 
5 sur la base des moyens fournis en i) et fournir des moyens lui 
permettant de s'authentifier de maniere anonyme aupres d'un Serveur , 
ili) authentifier le Client par la production d'une signature anonyme et 
ouvrir et maintenir une session d'authentification anonyme aupres d'un 
Serveur, et 

10 M permettre selectivement un contact entre le Serveur et I'Autorite de 
Certification Anonyme pour lever I'anonymat du Client sur la base de la 
signature fournie a I'etape Hi). 

L'etape i) consiste avantageusement pour un Client utilisateur a 
recuperer, aupres de I'Autorite de Certification Anonyme formant un 
15 tiers de confiance, les informations (une cle publique et un certificat) lui 
permettant de calculer des signatures anonymes. Tout serveur ou 
ressource peut verifier ces signatures sans que I'identite reelle de 
Tutilisateur ne lui soit revelee. Une signature valide garantie a la 
ressource ou serveur qu'il pourra, le cas echeant, recouvrer I'identite 
20 reelle de I'utilisateur en interrogeant le tiers de confiance. 

La presente invention propose ainsi une solution complete et 
globale pour : 

Garantir I'anonymat des clients : 1'invention repose sur des 
mecanismes d'authentification forte permettant de preserver I'anonymat 

25 des clients ; 

® Maintenir efficacement une session d'authentification : le 
mecanisme de maintien de session d'authentification que propose 
1'invention ne necessite aucun calcul cote client. Toutes les informations 
necessaires sont calculees au cours de la phase d'authentification ; 

30 © Responsabiliser les clients : L'invention permet de garantir 

la non-repudiation. D'une part, parce qu'a tout moment, le serveur peut 
lever I'anonymat d'un client en interrogeant un tiers de confiance. 
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D'autre part, parce que le serveur peut prouver chacune des actions 
d'un client. 

La presente invention concerne egalernent un systeme apte a 
permettre I'ouverture et le maintien d'une session d'authentification 

J 5 garantissant la non repudiation, caracterise par le fait qu'il comprend 
des rnoyens adaptes pour la mise en ceuvre de trois phases : 
. une premiere phase dans laquelle un Client calcule un ensemble de 
donnees, forme d'une suite de jetons, Tun de ceux-ci permettant 
d'ouvrir une session, tandis que les autres permettent de la maintenir, 

10 . une deuxieme phase dans laquelle le Client s'engage fortement sur la 
suite de jetons apres d'un Serveur, et 

. une troisieme phase de maintien de la session a I'aide de la suite de 
jetons. 

On notera que dans le contexte de ce systeme d'ouverture et de 
15 maintien de session, le Client dispose de rnoyens lui permettant de 
produire une signature digitale qui n'est pas obiigatoirement anonyme, 
• bien que preferentiellement elle le soit bien entendu. 

D'autres caracteristiques, buts et avantages de la presente 
invention apparaitront a la lecture de la description detaillee qui va 
20 suivre, et en regard des dessins annexes, donnes a titre d'exemples non 
iimitatifs et sur lesquels : 

- la figure 1 represente Tarchitecture generale des rnoyens relationnels 
mise en jeu dans le cadre de la presente invention, 

- la figure 2 represente un organigramme schematique du precede 
25 conforme a la presente invention, 

- la figure 3 schematise le processus d'identification forte, 

- la figure 4 schematise le processus de certificat anonyme, 

- la figure 5 schematise le processus de signature aveugle a anonymat 
revocable, 

30 - la figure 6 schematise le processus de signature de groupe, 

- la figure 7 schematise Tapplication de la presente invention a un 
processus d'encheres electroniques, 
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- la figure 8 schematise une etape preparatoire de mise en vente et 
consultation dans le contexte d'encheres electroniques, 

- la figure 9 schematise un exemple de fiche article mise a disposition 
d'un visiteur, Client potentiel, dans le cadre d'une vente aux encheres, 

5 - la figure 10 schematise, une etape d'obtention de certificat anonyme, 

- la figure 11 schematise les etapes d'inscription de groupe, generation 
de cles et envoi de certificat dans ce contexte, 

- la figure 12 schematise une etape de demande de participation avec 
certificat et autorisation, 

10 - la figure 13 schematise les etapes d'initialisation puis de generation de 
jetons par deux Clients respectifs dans le cadre d'encheres, 

- la figure 14 schematise une etape de participation a une vente aux 
encheres, 

- la figure 15 schematise les etapes de surencheres par transmission de 
15 jeton dont IMndice (ou "rang") represente la valeur choisie pour la 

surenchere, 

- la figure 16 schematise une etape de traitement des ordres 
d'encheres, 

- la figure 17 schematise le traitement d'un jeton regu d'un Client et la 
20 comparaison de la valeur representee par son indice avec les donnees 

anterieurement recues, 

- la figure 18 schematise une etape de conclusion de vente aux 
encheres, 

- la figure 19 schematise des etapes d'information de Client gagnant 
25 d'encheres, de Clients perdant, de vendeur et de fin de transaction, et 

- la figure 20 schematise une architecture Client-Serveur permettant de 
mettre en oeuvre le procede a la presente invention. 

Comme indique precedemment et illustre sur la figure 1 annexe, 
('invention met en oeuvre trois entites dans le protocole : des Clients C, 
30 au moins une Autorite de Certification Anonyme ACA et au moins un 
Serveur (ou "Ressource") Se. 
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Comme egalement indique precedemment, Pinvention propose, 
d'une part, un mecanisme d'authentification anonyme base sur 
['utilisation de certiflcat anonyme, Elle propose, d'autre part, un 
mecanisme de maintien de session economique et efflcace garantissant 
5 la non-repudiation. Enfin, elle propose une solution globale combinant 
les mecanismes d'authentification anonyme (ex. signature de groupe, 
certificat anonyme) et le mecanisme de maintien de session pour 
repondre aux problematiques suivantes : 

© L'anonymat des utilisateurs : Pinvention repose sur des 
10 mecanismes d'authentification forte permettant de preserver l'anonymat 
des utilisateurs, non seulement vis-a-vis des autres utilisateurs, mais 
aussi vis-a-vis des serveurs ; 

© L'efficacite et portability : le mecanisme de maintien de , 
• session d'authentification que propose Pinvention ne necessite aucun % 
15 calcul cote utilisateur. Toutes les informations necessaires sont calculees 
prealablement au cours de la phase d'authentification ; 

• La non-repudiation : ^invention permet de garantir la non- 4 
repudiation. D'une part parce qu'a tout moment, le serveup peut lever 
l'anonymat d'un utilisateur en interrogeant le tiers de confiance ACA. ; 
20 D'autre part parce que le serveur peut prouver chacune des actions d'un 
utilisateur. 

*> L'ergonomie : Putilisateur s'enregistre une seule et unique 
fois aupres d'un tiers de confiance ACA. 

L'Autorite de Certification Anonyme (ACA) delivre des certificats 
25 anonymes et est adaptee et habilitee pour lever l'anonymat le cas 
echeant. Le Serveur foumit des services a des personnes C desirant 
rester anonyme, cet anonymat pouvant etre leve quand cela est 
necessaire. Un Client va obtenir un certificat anonyme dans le but de 
s'authentlfier anonymement puis de maintenir une session aupres d'un 
30 Serveur. 

Le precede conforme a I'invention dans une mise en oeuvre 
preferentielle comprend essentiellement 4 etapes. 
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o Etape 1 : P identification. Le Client C s'enregistre aupres d'une 
autorite de confiance (cette autorite peut etre soit I'Autorite de 
Certification Anonyme elle-meme, soit une autorite de certification). 
Cette etape consiste pour Putilisateur a fournir des informations 
5 personnels (nom, prenom, adresse, etc .). Plusieurs alternatives sont 
possibles pour cela. Par exemple, le client peut s'enregistrer soit en ligne 
en remplissant un formulaire electronique, soit en se deplacant 
physiquement dans un endroit bien precis. L'autorite de confiance verifie 
Pidentite du client et toutes ou une partie de ses informations 
10 personnelles, stockent ces informations pour une utilisation future et 
fournit au Client les moyens (par exemple un login/mot de passe ou un 
certificat) qui lui permettront de s'authentifier aupres de I'ACA. II est a 
noter que dans tout le reste du protocole, le Client ne fournira plus a 
aucun moment ses donnees personnelles. 
15 • Etape 2 : I'authentification aupres de I'ACA. Cette etape met en 

jeu le Client et I'ACA. Le Client s'authentifie de maniere forte aupres de 
I'ACA (en utilisant les moyens qu'il a obtenus a Petape 1). L'ACA lui 
delivre en retour les moyens de produire une signature anonyme. Elle se 
garde les moyens de pouvoir relier a tout moment le Client (i.e. la 
20 personne physique qu'elle connait a Paide de Pa uthentifi cation forte) a 
n'importe quelle signature emanant de celui-ci. 

o Etape 3 : I'authentification anonyme aupres du Serveur. Cette 
etape met en jeu un Serveur et un Client. Ce dernier desire maintenir 
une session pour acceder aux services qu'offre le Serveur et doit pour 
25 cela faire savoir a ce dernier qu'il s'est authentifie de maniere forte 
aupres de I'ACA. Pour autant, le Client veut rester anonyme vis-a-vis du 
Serveur et d'autres clients potentiels. Le but de cette etape est d'ouvrir 
une session aupres due Serveur en faisant un certain nombre de calculs 
pour ensuite pouvoir maintenir cette session de maniere tres rapide. 
30 Cette etape va ainsi se diviser en trois phases. La premiere 

phase va permettre au Client de calculer un ensemble de donnees (une 
suite de jetons), Pun de ces jetons permettant d'ouvrir la session alors 
que les autres permettront de la maintenir. La deuxieme phase 
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permettra au Client de s'engager fortement sur cette suite de jetons 
aupres du Serveur. La troisieme phase consistera a maintenir la session 
a Paide de cette suite. 

Remarque 1 : Dans certains cas (par exemple lorsque le service 
5 d'anonymat est facture aux serveurs), PACA peut exiger une 
authentification des Serveurs qui veulent offrir le service d'anonymat a 
leurs utilisateurs. Pour ceia, PACA doit pouvoir exiger une 
authentification des serveurs avant de remettre un certificat anonyme a 
Putilisateur et/ou avant de lever Panonymat. Les serveurs dolvent done 
10 prealablement se soumettre & une phase d'enregistrement aupres de 
PACA. Pour cela, chaque serveur fait une demande d'affiliation a PACA 
qui etudie la proposition (suivant des criteres qu'elle a etablis) et decide 
d f accepter ou non la proposition. 

Remarque 2 : Les deux premieres phases necessitent un 
15 dialogue entre I'utilisateur et PACA d'une part (premiere phase), et entre 
Putilisateur et le serveur d'autre part (seconde phase). Elles seront done 
typiquement realisees en utilisant un navigateur web ou une application 
hebergee sur le poste du client. Toutefois, puisque la suite de jetons est 
pre-calculee au cours de la phase d'authentification, elle peut etre 
20 embarquee dans un terminal portable (telephone mobile, PDA, ...)• 
L'utilisateur peut done s'authentifier aupres du serveur en utilisant un 
navigateur ou une application et maintenir ensuite la session 
d'authentification en utilisant un autre type de terminal. 

Tous les jetons sont a usage unique et sont fortement 
25 dependants les uns des autres. lis ne peuvent etre calcules que par le 
Client et sont non-falsifiables. NMmporte qui, et en Poccurrence le 
Serveur, peut verifier la dependance (et done la provenance) de ces 
jetons. 

Dans un premier temps done, le Client, au cours de Pouverture 
30 de la session, calcule la suite de jetons. L'algorithme de generation des 
jetons est base sur Putilisation de deux primitives cryptographiques : 
une fonction de hachage et un nombre aleatoire. 

Une fonction de hachage HQ possede les proprietes suivantes : 
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- H(M) opere sur un message M de longueur arbitraire 

- Le resultat h = H(M) possede une longueur I fixe 

- Etant donne M, il est facile de calculer h 

- Etant donne M, il est difficile de trouver un autre message M 0 

5 tel que H(M) = H(M 0 ) 

Parmi les fonctions de hachage, nous pouvons citer MD5 
("Message Digest 5") ou SHA ("Secure Hash Algorithm"). SHA produit 
une sortie de 160 bits appelee message abrege. 

Afin d'initialiser I'ensemble des jetons, il est necessaire de 
10 generer un nombre aleatolre a partir duquel la fonction de hachage va 
calculer les jetons. Ce nombre aleatolre doit etre cryptographiquement 
sur, c'est-a-dire qu'il faut que la probability de reussite de la recherche 
exhaustive soit quasi nulle. 

La fonction de hachage appliquee a ce nombre aleatoire W 0 
15 permet d'obtenir un resultat W x (c'est-a-dire un premier jeton) auquel 
on applique a nouveau la fonction de hachage pour obtenir un deuxieme 
jeton W 2 et ainsi de suite pour obtenir n jetons : 
H(W 0 ) = W„ H(W n .!) = W„ 

La suite de jetons est done (W n ,W„.i,W„-2,...,Wi,W 0 ). Du fait des 
20 proprietes des fonctions de hachage, il est facile, a partir de W 0 , de 
calculer n'importe lequel des W, (pour i allant de 1 a n) alors qu'il est 
impossible en pratique de retrouver W„ a partir des W, (pour i allant de 1 
a n). 

Dans un second temps, le Client utilise ses moyens 
25 d'authentification forte anonyme obtenus a I'etape 2 pour produire une 
signature anonyme du jeton d'initialisation Wn, la signature permettant 
au serveur d'authentifier ce Client (il peut verifier la validite de la 
signature et done etre convaincu des droits du client qu'il a en face de 
lui). Le Client vient ainsi d'ouvrir une session anonyme aupres du 
30 Serveur. II va pouvoir maintenir cette session a I'aide de la suite de 
jetons. Le jeton W n est stocke par le Serveur et sera utilise pour verifier 
la validite des autres jetons (et done de la session). 
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Remarque : Au cours de la phase d'authentification anonyme, un 
certain nombre dMnformations peuvent etre associees au jeton 
dMnitialisation (par exemple, la valeur numeraire d r un jeton). Ces 
informations constituent les informations de session et permettent de 
5 decrire la semantique associee a chaque jeton. Un jeton permettra done 
au serveur de retrouver Pidentite de Pemetteur mais egalemeqt les 
informations de session. 

Au cours de la session, le Serveur veut etre sur de pouvoir 
retrouver i'identite physique du client quMI a en face de lui, selon le 
10 principe defini a la quatrieme etape. De plus, il faut que cette 
authentification se fiasse rapidement. Pour cela, le Client transmet 
simplement, a chaque nouvelle authentification, un jeton de la liste 
calculee precedemment : W n -i, puis W n - 2 /W n -3/ ... Pour poursuivre la 
session, le Client transmet ainsi les jetons dans I'ordre de n - 1 a 0. 
15 . D'une maniere generate, si le resultat de h(W n -i) est bien egal a 

W n alors I'authentificatton est acceptee. Le Serveur est capable de 
verifier ce lien : le jeton W| regu est compare avec les jetons de 
I'ensemble des clients presents dans la base. Ainsi, pour trouver dans la 
base le W k relie au W, regu, il utilise la formule : h^W,) = W k (en utilisant 
20 le fait que h 2 (W n - 2 ) : =h(h(W n -2))=h(W n - 1 )=Wn). Si le Serveur parvient a 
trouver dans sa base ce jeton W k , alors il accepte la poursuite de la 
session et le jeton W| remplace le jeton W k pour la verification suivante. 
Dans le cas contraire, le jeton n'appartient pas a un client et 
Tauthentification est refusee. 
25 Lors des diverses authentications se deroulant au cours de la 

session, le Serveur sait ainsi toujours relier un jeton (et done la 
session) a la signature anonyme effectuee au moment de Touverture de 
cette session. 

• Etape 4 : Elle met en jeu un Serveur et PAutorite de confiance. 
30 Le premier a en sa possession une signature quMI sait emanant d'un 
Client s'etant identifie de maniere forte aupres de I'ACA. S'il le souhaite, 
il peut done envoyer cette signature a I'ACA qui a les moyens de 
decouvrir IMdentite physique du signataire (cf. premiere etape) et de 
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fournir cette information au Serveur. Ce dernier peut ainsi obtenir 
I'identite physique du Client ayant produit la signature et I'ensemble des 
jetons qu'il a recu au cours de sa session. 

Une variante consiste a faire en sorte que le Serveur ne 
5 connaisse a aucun moment I'identite du Client. Dans ce cas, une fois la 
levee d'anonymat effectuee par I'ACA, ce dernier contacte 
personnellement le Client implique et termine ainsi la session de la 

maniere adequate. 

Dans certains cas, le droit de production de signature anonyme a 
10 une duree de vie limitee (par exemple liee a une seule session). Dans ce 
cas, le Client devra s'authentifier de maniere forte aupres de I'ACA a 
chaque session (i.e. pour chaque suite de jeton). 

Le nombre de sessions iiees a un engagement est limite dans le 
temps. En effet, la suite de jetons est finie. Une fois le dernier jeton 
15 envoye, le Client doit produire une nouvelle suite de jetons aupres du 
Serveur et doit signer anonymement le jeton d'initialisation. 

D'autre part, I'etape 3 peut etre utilisee seule pour ouvrir et 
maintenir efficacement une session d'authentification. Ainsi, un Client va 
pouvoir s'authentifier de maniere forte aupres du serveur (mais sans 
20 anonymat cette fois-ci) et maintenir une session, de maniere tres 
rapide, a I'aide de la suite de jetons qu'il aura prealablement calcules. 
Cette approche permet, en outre, de garantir la non-repudiation. 
DESCRIPTION DETAILLEE D'UN MODE DE REALISATION 
Specification du mecanisme de jetons 
25 Jeton d'initialisation 

Le premier jeton envoye par le Client au Serveur est appele 
jeton d'initialisation et permet d'ouvrir la session. II est lie, a la fois, a 
l'authentification du Client a partir d'une signature et aux informations 
de session. Ainsi, le jeton d'initialisation fixe par association, dans un 
30 message envoye par le Client au Serveur, la preuve d'authentification et 
ies parametres d'initialisation de la session. 

Dans le cas des encheres, dont ('application est decrite par la 
suite, le mecanisme de jetons est utilise dans la phase de participation a 
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une vente. Un Client demande une participation a la vente aux encheres 
en transmettant un message compose du jeton dMnitiaiisation associe 
aux parametres de la vente, par exemple, IMdentifiant de Particle, son 
prix actuel, et la valeur du pas. Cest ce message qui est signe. Le Client 
5 transmet egalement, dans cette demande de participation, les moyens 
pour le serveur de verifier la signature (message, cle publique, 
certificat...) et done d'authentifier le Client, en fonction du mecanisme de 
signature utilise, Des specifications du mecanisme de signature seront 
decrites ci-dessous. 
10 Si Tauthentification du Client par le Serveur est valide, le jeton 

dMnitiaiisation et les donnees transmises par le Client, dans cette 
demande de participation, sont enregistres par le Serveur d'Encheres. 
Jetons de maintien de session 

Dans le cas des encheres, sf le Serveur autorise le Client a 
15 participer a la vente apres avoir regu le jeton dMnitiaiisation, le Client, 
peut alors surencherir en envoyant au Serveur les jetons successifs et 
seulement les jetons. En effet, chaque ordre d'enchere du Client se 
traduit par renvoi d'un jeton sans autre information ni signature. A 
partir des informations enregistrees avec le jeton dMnitiaiisation, le 
20 Serveur est capable d'authentifier I'ordre en attribuant le jeton a son. 
Client proprietaire et de calculer sa valeur. Ainsi, chaque jeton regu par 
le Serveur est compare avec Tensemble des jetons enregistres. Par 
dependance entre jetons, le nouveau jeton regu par le Serveur ne peut 
correspondre qu'a un seul jeton present dans la base. Le Serveur 
25 retrouve les informations slir le Client et sur Tarticle lie au jeton regu en 
le mettant en correspondence avec un jeton stocke et un seul. Selon ce 
procede, le mecanisme de jetons peut s'appliquer aux encheres en 
etablissant des regies de calcul. 

Cote client, le calcul de IMndice i du jeton Wi pour surencherir 
30 (prixsup) est base sur le prix actuel de ('article (prixmax) et du pas de 
Tarticle (pas). Les formules peuvent etre : 

prixsup = prixmax + pas 

j = (prixsup - prixdedepart)/pas 
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i = nombretotaldejetons - j 

Cote serveur, le jeton W t recu est compare avec les jetons 
presents dans la base. Les formules permettant de retrouver le jeton et 
de calculer sa valeur peuvent etre : 
5 - Pour trouver dans la base W k , la formule est : h'(W,) = W k 

- Pour calculer la valeur de W,, la formule est : W, = prixdeW k + 

(I *pas) 

Specification du mecanisme de signature du jeton d'initialisation. 

La signature du jeton d'initialisation permet I'ouverture d'une 
10 session et peut etre realisee, selon les cas, avec ou sans anonymat. Le 
Client possede une cle privee SK, une cle publique PK et un certificat 
(anonyme ou non). II utilise sa cle privee SK et un algorithme 
cryptographique (par exemple RSA, DSA ou signature de groupe) pour 
signer un message compose du jeton d'initialisation Wn et des 
15 informations de session session_data. II obtient ainsi une signature S- 
Sigsk (Wn, session_data) qu'il envoie au Serveur avec le message, sa cle 
publique PK et le certificat C qui relie cette cle publique a son identite 
propre. 

La figure 3 schematise les details du protocole de signature du 

20 jeton d'initialisation. 

Specification des mecanismes de signature anonyme. 

Certificat anonyme 

Lors de la seconde etape, le Client C cree une paire de cles 
publique PK - privee SK (par exemple des cles RSA). II garde secret la 

25 cle privee et envoie a I'ACA la cle publique PK afin d'obtenir, lors d'une 
session authentifiee fortement, un certificat AC=Sig ACA (PK, Pseudo) de 
cette cle liee a un pseudonyme choisi par I'ACA et/ou le Client. Ce 
pseudonyme peut eventuellement etre le chiffrement de la veritable 
identite du Client accompagnee d'un alea. La levee de I'anonymat se fait 

30 ainsi facilement par I'ACA qui dechiffre ce pseudonyme pour obtenir 
I'identite du Client. L'ACA garde en memoire le lien entre le Client et son 
pseudonyme pour, par la suite, pouvoir lever I'anonymat. 
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Remarque : D'une maniere generate, un certificat anonyme 
permet de Her un pseudonyme a une cle publique. Mais il peut 
egalement, en fonction du contexte, contenir d'autres informations 
permettant de limiter la portee du certificat (ex. Pidentifiant du serveur, 
5 Pidentifiant d'une session, une date de validite, P.adresse IP du client, le 
contexte d'authentification ...). 

L'etape de signature du jeton d'initialisation consiste pour le 
Client a utiliser sa cle privee PK (il s'agit done d'une signature RSA). Le 
message est constitue du jeton d'initialisation W1000, de la signature S, 
10 de la cle publique PK et du certificat lie au pseudonyme AC+Pseudo. Le 
Serveur ouvre done une session avec un client qu'il ne connait que sous 
un pseudonyme. II verifie ainsi que le Client s'est authentifie fortement 
aupres de PACA h Paide du certificat AC et que la cle publique PK * 
certifiee. (et appartenant au pseudonyme) permet bien de verifier la.,.; 
15 signature du jeton dMnitialisatiqn. ...^ 
La levee de Panonymat est mise en oeuvre lorsque le Serveur,.., 
fournit a PACA le certificat (ou le pseudonyme). L f ACA peut savoir a quel £ 
Client correspond ce pseudonyme et done qui a produit la signature. 

La figure 4 schematise les details des protocoles de certificat.. 
20 anonyme. 

II est a noter que pour obtenir un anonymat interessant, il 
convient de changer de certificat (et done de paire de cle de signature) a 
chaque session. II faut done que le Client se connecte a PACA a chaque 
session. 

25 Remarque : si le Client desire se connecter a plusieurs serveurs 

beneficlant des services de PACA, au moins deux possibilites s'offrent a 
lui. Soit PACA fournit un seul certificat (universel) pour Pensemble des 
serveurs, auquel cas il est possible de tracer le pseudonyme de ce Client 
sur Pensemble des sites (on ne sait pas qui il est mais on sait ce qu'il 

30 fait sur chacun des serveurs). Soit PACA fournit un certificat par serveur 
, auquel cas on perd Puniversalite du certificat mais il est alors 
impossible de tracer un meme client sur plusieurs serveurs. 
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Chaque serveur fournit au Client un identifiant qui est retransmit 
a I'ACA. Ce dernier sait alors qu'il a fournit a tel Client un certificat pour 
tel Serveur et done n'en fournira pas deux. 

Remarque : de meme, si le Client possede deux machines a 
5 partir desquelles il desire acceder au Serveur (par exemple une machine 
a son lieu de travail et une machine chez lui), il doit pouvoir obtenir. 
deux certificats differents de la part de I'ACA. 

Certificat aveugle a anonymat revocable 

Une partie du processus conforme a la presente invention peut 
10 s'apparenter a un certificat aveugle a anonymat revocable. 

Le concept de schema de signature aveugle a ete introduit par 
Chaum a Crypto'83. Un schema de signature aveugle est un protocole 
mettant en jeu deux entites : un signataire et un utilisateur. II permet a 
I'utilisateur d'obtenir la signature d'un message donne faite par le 
15 signataire, sans que ce dernier n'apprenne quoi que ce soit a propos du 
message. 

Le modele de la signature aveugle a anonymat revocable est 
constitue de plusieurs utilisateurs, d'un signataire, d'une autorite 
reconnue, par exemple un juge, et de deux protocoles : 
20 - Un protocole de signature entre le signataire et I'utilisateur. 

- Un protocole de recouvrement entre le signataire et le juge. 

A I'aide du protocole de signature, I'envoyeur obtient une 
signature valide du message de son choix de telle sorte que le signataire 
ne peut pas relier le protocole et la paire message/signature. II existe 
25 deux types de signature aveugle a anonymat revocable, suivant 
I'information que le juge regoit du signataire pendant le second 
protocole : 

- Revocation de type 1 : a I'aide de la partie du protocole venant 
du signataire, le juge donne I'information qui permet au signataire (ou a 

30 n'importe qui) de reconnaTtre le message (i.e. le juge peut retrouver le 
message). 
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- Revocation de type 2 : a I'aide du message et de la signature, 
le juge permet au signataire de retrouver efficacement I'utilisateur ou la 
partie du protocole correspondant a la signature. 

On se reportera aux documents [6], [7], [8], [9], [10] et [11] 

5 pour disposer d'exemples de schema de signature aveugle a anonymat 
revocable (en anglais "fair blind signature"). 

Dans le cas de I'invention (revocation de type 2), PACA joue le 
role du signataire et le Serveur joue celui de juge. Le Client est 
I'utilisateur. Lors de la premiere etape, le Client cree une paire de cles 

10 publique PK - privee SK (par exemple de type RSA). II garde secret la 
cle privee de signature et envoie a I'ACA la cle publique PK afin 
d'obtenir, lors d'une session authentifiee fortement, une signature 
aveugle BC a anonymat revocable (protocole d'obtention de certificat) 
de cette cle (la signature aveugle correspond a son certificat anonyme). 

15 L'ACA garde en memoire les moyens de lever I'anonymat de cette 
signature. Sur la figure 5, cette signature aveugle est intitulee 

BC=BSig ACA (PK). 

L'etape de signature du jeton d'initialisation (protocole de 
signature de jeton) consiste pour le Client a utiliser sa cle privee PK pour 

20 signer (il s'agit done d'une signature RSA). Le message est constitue du 
jeton d'initialisation W1000, de la signature S, de la cle publique PK et 
du certificat anonyme BC. Le Serveur verifie ainsl que le Client s'est 
authentifie fortement aupres de I'ACA a I'aide du certificat anonyme (il 
verifie que la signature BC emane bien de I'ACA) et que la cle publique 

25 PK certifiee permet bien de verifier la signature S du jeton 
d'initialisation. 

La levee de I'anonymat est mise en ceuvre lorsque le Serveur 
fournit a I'ACA le certificat anonyme BC. L'ACA peut savoir a quel 
moment il a produit cette signature (protocole de levee d'anonymat) et 
30 done a qui est ce qu'il I'a fourni. 

La figure 5 schematise les details des protocoles de certificat 
aveugle a anonymat revocable. 



20 



II est a noter que dans ce cas, il convient d'obtenir une signature 
aveugle pour chaque session (il est ainsi impossible de relier deux 
sessions d'un meme client). II faut alors que le Client se connecte a 
I'ACA avant chaque debut de session. 
5 On retrouve le meme probleme (et les memes solutions) que 

pour le certiflcat anonyme dans le cas de plusieurs serveurs ou de 
plusieurs machines par client. 
Certiflcat de groupe 

L'invention peut egalement mettre en oeuvre une signature de 

10 groupe. 

Une signature de groupe permet aux membres d'un groupe de 
produire une signature telle que le verificateur reconnaitra cette 
signature comme ayant ete produite par un membre du groupe, tout en 
ignorant de quel membre il s'agit. Cependant, une autorite de confiance 
15 a la possibility de lever a tout moment cet anonymat et done de reveler 
I'identite du signataire. De telles signatures sont bien souvent "non- 
correlables" : il est impossible de determiner si deux signatures ont ete 
emises par la meme personne ou non. 

Dans tout schema de signature de groupe, est attribuee au 
20 groupe une unique de publique de groupe, tandis que sont attribues a 
chaque membre de ce groupe un identifiant et une de privee qui lui sont 
propres. A I'aide de sa de privee, un membre du groupe peut produire 
une signature de groupe d'un message de son choix, laquelle signature 
peut etre veriflee par une entite quelconque a I'aide de la cle publique 
25 de groupe. La verification apprend seulement a cette entite que la 
signature a ete produite par un membre du groupe, mais ne lui donne 
aucune information sur I'identifiant du membre qui a signe. En 
revanche, I'autorite de confiance dispose d'une information 
supplemental qui lui permet de retrouver I'identifiant de ce membre, 
30 et done de lever cet anonymat a tout moment (on dit que I'autorite de 
confiance "ouvre" la signature). On se reportera aux documents [1], [2], 
[3] et [4] pour des schemas de signature de groupe. 
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Dans le cas de ^invention, l'ACA joue le role d'autorite de 
confiance. Au cours de la premiere etape, un Client va s'inscrire a unn 
groupe aupr&s de l'ACA en mteragissant avec lui afin d'obtenir un 
certificat de membre GC (protocole d'enregistrement d'un membre). 
5 L'ACA se garde les moyens d'ouvrir une signature, ie cas echeant. 

L'etape de signature du jeton d f initialisation W1000 consiste a 
produire une signature de groupe S de cet element (protocole de 
signature de groupe) soit S=Sig GP (W1000). Ainsi, le signataire est 
anonyme au seln du groupe. Le Serveur a les moyens de verifier qu'une 
10 signature a bien ete emise par un membre du groupe (protocole de 
verification de signature de groupe) mais sans pour autant savofr de 
quel membre il s'agit. 

Enfin, l'ACA, en temps qu'autorite de confiance, a les moyens 
d'ouvrir la signature (protocole d'ouverture de signature de groupe) 
15 pour lever I'anonymat et divulguer I'identite du signataire. 

La figure 6 schematise les details des protocoles de certificat de 

groupe. 

II est a noter que, du fait des proprietes d'anonymat et de non- 
reliabilite des signatures de groupe, ii n'est pas necessaire de 

20 s'enregistrer au groupe pour chaque session. Le fait d'etre inscrit au 
groupe permet de faire autant de signature de groupe que le Client le 
desire sans pour autant que quelqu'un puisse relier deux de ses 
signatures. Ce certificat unique peut etre utilise chez plusieurs serveurs 
sans risque de pouvoir tracer le client. De meme, un client possedant 

25 plusieurs machines n'aura pas besoin d'obtenir plusieurs certificats. 

Remarque : Une propriete interessante des approches basees 
sur les signatures de groupe et les signatures aveugles est qu'elles 
permettent de repartir les fonctions de generation de certificats et le 
pouvoir de levee d'anonymat entre deux ou plusieurs autorites. Selon ce 

30 prindpe, la levee de I'anonymat d'un utilisateur ne sera possible que si 
Tensemble de ces autorites Tautorise. Ce processus est moins naturel 
dans le cas des certifications anonymes. 
EXEMPLE DE REALISATION 
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On va maintenant decrire plus particulierement 1'application de la 
presente invention aux encheres electroniques. 

L'application presentee id pour illustrer le precede conforme a 
i'invention appartient au domaine du commerce electronique sous la 
5 forme des ventes aux encheres sur Internet. 

Le principe de ventes retenu est celui des encheres classiques ou 
un article est mis aux encheres croissantes entre plusieurs encherisseurs 
et pendant un temps determine. Cette realisation s'appuie sur les 
technologies Java (applet, servlet, jsp) en architecture client-serveur 
10 avec un systeme de gestion de base de donnees relationnel. 
1 Probteme soecifique aux encheres resolu par le prece de 
1.1 But 

Le procede offre une solution innovante pour securiser les 
encheres electroniques et permettre de realiser des transactions en 
1 5 toute confiance. 

Actuellement, les encheres en ligne ne presentent pas des 
niveaux de securite suffisants dans le cas d'encheres de grandes valeurs 
et pour des participants scrupuleux de preserver leur anonymat. 
L'organisation de ventes aux encheres publiques de plusieurs milliers 
20 voire plusieurs millions d'euros reclament de nouveaux mecanismes. 

La cryptographie utilisee dans le cadre de I'invention permet de 
repondre aux objectifs. Les informations transmises sont inintelligibles a 
des personnes exterieures a la transaction pour des raisons de 
confidentialite. 

25 Le procede assure la non-repudiation pour garantir que le client 

ne peut pas nier avoir fait acte de surenchere. 

Le procede assure I'integrite des donnees echangees. 
Le procede permet d'assurer I'identite d'un utilisateur par 
authentifi cation. 

30 De plus, le procede est rapide pour la prise en compte en temps 

reel des ordres d'encheres. 

1.2 Innovation et avantages techniques du procede applique aux 

encheres 
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Le mecanisme de jetons signes avec anonymat est adapte aux 
encheres. Avec ce procede, un acheteur peut etre autorise a participer 
aux encheres sans risque d'infractions liees a la divulgation de son 
identite. Personne ne peut se faire passer pour un autre et seuls les 
5 membres inscrits et autorises peuvent participer aux encheres. 

Le systeme actuel connu de login/mot de passe est tres repandu 
mais il ne presente pas toutes les garanties. Un programme 
informatique peut facilement capturer I'information transmise en clalr 
sur Internet et offrir ainsi la possibility a un usurpateur de voler un mot 
10 de passe. Si un protocole comme SSL permet de se premunir contre ce 
type d'attaques, il ne permet pas en revanche de lutter contre les 
attaques a base de dictionnaires de mots de passe. En effet, ces 
attaques peuvent permettre de casser facilement des mots de passe 
trop courts et trop simples. 
15 La caracteristique des jetons utilises dans le procede conforme a 

Pinvention est son usage unique. II ne peut servir que pour un ordre 
. d'enchere et un seul, et ne devoile aucune information sur son 
utilisateur. II permet juste de verifier que la requete transmise 
appartient bien a un utilisateur precis. Ici, un ordre d'enchere Identifie 
20 par un mot de passe jetable est certifle appartenir a un acheteur 
particulier pour une valeur unique. 

Les jetons sont envoyes par !e client C au serveur d'encheres Se 
pour encherir sur un produit. La presentation au debut de I'enchere d'un 
premier jeton, note W1000 pour le client 1 et X1000 pour le client 2, 
25 sert d'initialisation et de preuve pour la suite de la vente (voir figure 7). 
A partir de ce mecanisme de jetons, le principe est de signer le premier 
jeton envoye pour enregistrer la demande de participation d'un client. 
Les jetons transmis pour encherir sont verifies a partir de ce premier 
jeton d'initialisation, conform^ment au processus precedemment decrit. 
30 Les jetons suivants represented les surencheres. Par exemple, 

si un client (client 1) participe a une enchere avec un prix de depart a 
1000 et un pas a 100, il peut proposer d'encherir a 1100 en 
transmettant un jeton (W999). Pour encherir a 1400 et battre un autre 
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acheteur monte a 1300, II devra reveler le jeton correspondant au prix 
de 1400 soit le jeton W996. 

Ce processus est schematise sur la figure 7. 
? Mnrtelisation du svsteme 
5 2.1 Schema general 

[.'application de ventes aux encheres fait appel aux trois entites 
definies precedemment dans le procede : 

L'Autorite de Certification Anonyme (ACA) est placee sur un 

serveur d'anonymat (SA); 
10 - Le serveur Se fournisseur de services est ici le serveur 

d'encheres ; 

Le client C. 

Nous trouvons egalement dans cette application un serveur de 
certificat (SC) qui fournit un certificat pour I'authentification forte. 
15 Les fonctions principals du systeme d'encheres electroniques 

sont : 

La phase preparatoire : qui consiste a mettre en vente, 
consulter et obtenir un certificat anonyme; 

La phase d'encheres : qui consiste a demander et verifier 
20 une participation a une vente, encherir et verifier I'encherissement dans 

le but d'acquerir un article; 

La phase conclusion : qui consiste a mettre un terme aux 
encheres, valider et identifier un gagnant en levant I'anonymat, clore la 
vente. 

25 Chacune de ces fonctions va etre detaillee par la suite. 

2.2 Mise en vente et consultation 
Cette fonction est schematisee figure 8. 

Phase du deroulement : Preparatoire ; 

Niveau de securite : Assurer I'authenticite du serveur 

30 d'encheres ; 

Precondition : ConnaTtre le site d'encheres ; 
Objectifs : Faire connaitre les articles mis en vente ; 
Acteur principal : Visiteur, Vendeur, Administrates ; 
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Scenario typique : M.Martin est un collectionneur d'art, il 
decide d'acquerir une oeuvre mise en vente sur le site d'encheres. II se 
connecte au site et demande a afficher le catalogue des articles a 
vendre. Parmi les articles, il s'interesse plus particulierement a une 
5 photographie intitulee Regards dont le prix de depart est 600 euros et 
vendu par M.LeVendeur. II clique alors pour obtenir la fiche article, 
illustre a titre d'exemple sur la figure 9. 

2.3 Obtention d'un certificat anonyme 
Cette fonction est schematisee sur la figure 10. 
10 - Phase du deroulement : Preparatoire; elle correspond a la 

premiere etape du precede; 

Niveau de securite : Obtenir 1'anonymat avec la signature 

de groupe ; 

Contrainte : Double certification ; 
15 - Precondition : Authentication forte (etape 1 du precede), . 

choisir un serveur d'anonymat (SA) ; 

Objectifs : S'authentifier pbur participer a une vente aux 
encheres tout en etant anonyme ; 

Acteur principal : Visiteur et SA; 
20 - . Scenario typique : M.Dupond est toujours decide a 

participer a la vente aux encheres pour une oeuvre d'art dont le prix de 
depart est 500.000 euros. II souhaite rester anonyme pour cette vente 
afin de ne pas reveler ses moyens financiers ni son interet pour le type 
d'oeuvre a vendre, et, sMl gagne I'enchere, il ne veut pas que Ton sache 
25 qu'il devient le nouveau proprietaire. Rester anonyme tout en signant 
est rendu possible grace a la signature de groupe. M.Dupond fait done 
appel aux services d'une autorite de certification delivrant une signature 
de groupe. II s'inscrit a un groupe qui verifie son identite avant de lui 
foumir les moyens de creer ses cles et de I'enregistrer comme membre 
30 certifie. Un tel processus est schematise figure 11. 

2.4 Demande de participation avec certificat et autorisation 
Cette fonction est schematisee figure 12. 
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Phase du deroulement : Enchere ; elle fait partie de la 

troisieme etape du procede; 

Niveau de securite : Certificat et applet signee de 

generation de jetons d'encheres; 
5 - Precondition : Pour le client, avoir un certificat, avoir choisi 

un article, autoriser le chargement des applets signees; pour le serveur 
d'encheres, avoir obtenu les moyens de verifier une authentication 
anonyme (deuxieme etape du procede); 

Objectifs : Participer a une vente aux encheres ; 
10 - Acteur principal : Client ; 

Scenario typique : Afin de participer a I'enchere, M.Dupond 
presente sa demande a I'aide d'un jeton signe. Ce premier jeton, note 
W1000 pour M.Dupond et X1000 pour un autre client (voir figure 13), 
sert d'initialisation et de preuve pour la suite de la vente. Ce premier 
15 jeton est genere et signe par le client avec sa cle privee grace a une 
applet transmise par le site d'enchere. Le jeton est associe aux 
parametres de la vente, identifiant de Particle, prix actuel et valeur du 
pas. Pour M.Dupond, la signature est anonyme grace a la signature de 
groupe. 

20 2.5 Participation a une vente aux encheres 

Cette fonction est schematisee figure 14. 

Phase du deroulement : Enchere ; elle fait partie de la 

troisieme etape du procede; 

Niveau de securite : Le jeton assure ('authenticity 

25 I'integrite et la confidentiality de I'ordre d'enchere ; 

Precondition : Etre inscrit a la vente, le jeton possede une 

filiation ; 

Objectifs : Soumettre un ordre d'enchere pour rem porter la 

vente ; 

30 - Acteur principal : Client ; 

Scenario typique : M.Martin participe a la vente aux 
encheres de la photographle qull a choisi avec un prix de depart a 600 
euros et un pas a 10 euros. II est le premier encherisseur et il s'engage 
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a encherir a 610 euros en transmettant un jeton (W999). Au cours. de 
I'enchere, un deuxieme client augmente ie prix a 620 euros. M.Martin 
est pret a mettre plus et clique sur le bouton pour surencherir a 630 
euros. II transmet alors le jeton d'indice 997, note W997. En effet, 
5 comme decrit precedemment, chaque jeton correspond a une valeur 
calculee en fonction du prix de depart et du pas de I'enchere. 

Dans cette vente, I'indice 999 represented valeur 610 euros, 
998-620, 997-630, 996-640, ... ; 

Un tel processus est schematise figure 15. 
10 2.6 Traitement des ordres d'encheres 

Cette fonction est schematise figure 16. 

Phase du deroulement : Enchere ; eile fait partie de la. 
troisieme etape du procede; 

Niveau de securite : Le jeton assure ('authenticate du client . 
15 et I'integrite des donnees ; 

Precondition : Avoir un jeton d'initialisation pour les 
encheres d'un client particulier sur un article ; 

Objectifs : Comparer les ordres d'encheres, enregistrer les 
ordres et informer de devolution des encheres ; 
20 - Acteur principal : Client ; 

Scenario typique : Lorsque M.Martin clique sur le bouton 
pour encherir, un jeton correspondant au prix est envoye au serveur 
d'encheres. Cote serveur, le jeton permet de retrouver les informations 
necessaires a I'ordre d'enchere, c'est-a-dire sa valeur, son proprietaire 
25 (M.Martin) et I'article vise. Pour connaitre la position de M.Martin, son 
ordre est compare aux ordres des autres clients. La proposition de 
M.Martin est enregistree et le prix de la photo est actualise. 
Ce processus est schematise figure 17. 
2.7 Conclusion de la vente 
30 Cette fonction est schematise figure 18. 

Phase du deroulement : Conclusion de la vente ; elle 
comporte la quatrieme etape du procede; 
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Niveau de securite : Identifier le gagnant et lever 
I'anonymat du gagnant en cas de signature de groupe ; 

Objectifs : Determiner un gagnant et clore la transaction ; 
Acteur principal : Client, Vendeur, SA, Tiers de confiance ; 
5 - Scenario typique : Le temps de la vente ecoule, le systeme 

determine si M.Dupond a gagne ou non I'enchere en comparant les 
differentes propositions. L'offre de 800.000 euros est la plus forte et 
M.Dupond (anonyme) remporte I'oeuvre d'art. Les autres clients sont 
prevenus qu'ils ont perdu. Le vendeur est informe que son article a 
10 trouve un acheteur. Le Tiers de Confiance est alors charge de lever 
I'anonymat de M.Dupond et de clore la transaction en tant 
qu'intermediaire entre M.Dupond et le vendeur. Ce processus est 
schematise figure 19. 

2.8 Remarques 

15 _ inscription pour la participation a une vente : L'inscription a 

une vente est liee a une session. II est done necessaire de reinitialiser 
l'inscription en cas de deconnexion ou de changement de session ; 

- Usage des certificats : Les certificats d'authentification forte et 
les certificats anonymes sont multi-usages. II est done possible d'utiliser 

20 un certificat pour plusieurs ventes sans avoir a renouveler les demandes 
a chaque vente, sauf en cas de revocation ou d'expiration du certificat; 

- Proprietes a la demande du certificat anonyme : Lors de la 
connexion entre un client et le site serveur d'anonymat, la 
confidentialite et I'integrite des informations transmises et la garantie 

25 d'anonymat du client vis-a-vis de I'exterieur sont assurees par un 
protocole de communication par exemple SSL ; 

- Anticipation pour une premiere participation : La configuration 
de I'environnement technique du poste client (applet cryptographique 
signee) et les demarches d'obtention de certificats reclament une 

30 preparation a la participation a une vente. 
3 S pecification Hp I'appli ration d'encheres 

Cette partie decrit succinctement I'API pour les services de 
I'application aux niveaux suivants : 
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Demande d'un certificat anonyme et de participation a une 

vente; 

- . Controle de demande de participation; 

Enchere; 

5 - Verification d'enchere; 

Conclusion de la vente. 
Les etapes indiquees par une * sont considerees comme 
basiques dans le cadre du procede conforme a Finvention. 

3.1 Demande d'un certificat anonyme et de participation a une 

10 vente 

- S'authentifier de maniere forte aupres de FACA* 

- Generer les cles* 

- Envoyer la cle publique a FACA* * 

- Obtenir un certificat anonyme aupres de FACA* 

15 - Generer les jetons* t % 

- Stocker les jetons* 

- Signer le jeton d'initialisation et lid article* * 

- Transmettre le jeton signe, le certificat et rid article signe* 

- Recevoir la confirmation * 
20 - Afficher la confirmation 

3.2 Controle de demande de participation 

- Recuperer les moyens de verifier une authentification anonyme 
aupres de FACA* 

- Recevoir les donnees de i'applet 

25 - Verifier la signature avec les moyens de FACA* 

- Se connecter a la base de donnees 

- Enregistrer les donnees jeton, certificat, id article 

- Selecttonner dans la base le prix max de I'article 

- Transmettre la confirmation 
30 3.3 Enchere 

- Actualiser le prix max 

- Calculer le jeton par rapport au prix superieur 
W, ? 
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prixsup = prixmax + pas 

j = (prixsup - prixdedepart)/pas 

j = nombretotaldejetons - j 

- Transmettre le jeton* 
5 - Recevoir la reponse 

3.4 Verification d'enchere 

- Decompter le temps de la vente 

- Recevoir le jeton (W t )* 

- Verifier le jeton (trouver dans la base W u tel que h'(W,) = W k )* 
10 - Selectionner les donnees de la base pour W k 

- Selectionner le prix max de lid article 

- Calculer le prix correspondant au jeton recu W, 
prix de W, = prix de W k +(l* pas) 

- Comparer le prix max au prix de Wi 
15 - Enregistrer le prix de W t (UPDATE) 

- Repondre au client sur sa situation 
3.5 Conclusion de la vente 

- Detecter la fin de I'enchere 

- Determiner I'offre la plus haute 
20 - Lever I'anonymat* 

- Informer I'acheteur gagnant 

- Informer le vendeur 
4 Or ganisation technique 

4.1 Architecture client - serveur 

25 Cette architecture est schematisee figure 20. 

On y retrouve un navigateur Client, un Serveur ACA et un 
Serveur Se encheres (ces derniers etant chacun associe a une base de 
donnees specifiques) aptes a mettre en oeuvre les etapes precitees. 

4.2 Outils de prototypage : Base de donnees, serveur 

30 d'applicatton et Plug-in Java 

La base de donnees utilisee par les inventeurs pour un 
prototypage de cette application est une base Oracle 81. Oracle est un 
SGBD (systeme de gestion de bases de donnees) relationnel edite par la 
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societe du meme nom. Oracle dispose d'un langage permettant la 
definition et la manipulation des donnees : le langage SQL (Structured 
Query Language), qui est devenu le langage normalise dans le domaine 
des bases de donnees relationnelles. SQL*PLUS est Interface utilisateur 
5 d'Oracle qui permet d'utiliser interactivement le langage SQL sur une 
instance Oracle. 

Le langage de programmation et les technologies utilisees pour 
I 'implantation sont Java. L'application est geree par le produit d'IBM 
WebSphere 3.5. WebSphere Application Server permet de realiser des 
10 transactions et des interactions Web. II fournit une plate-forme portable 
de deploiement d'applications Web Java, axee sur la prise en charge et 
I'execution de servlets, de JavaBeans et de fichiers Java Server Pages 
(JSP). C'est une interface avec le serveur Web pour gerer les requetes - 
client portant sur les ressources cdte serveur et pour les acheminer vers 
15 le serveur d'applications en vue de leur traitement. L'outil utilise dans. 
WebSphere est le moteur de servlet. II s'execute a I'interieur du serveur 
d'applications et gere les requetes relatives aux servlets, aux fichiers 
Java Server Pages (JSP) et aux applications Web qui les contiennent. 

Le poste client a ete teste sur un systeme Windows avec le Plug- 
20 in Java. Le Plug-in (fournit par Sun) permet d'actualiser la version de la 
JVM du navigateur (IE ou Netscape). Le Java-plugin remplace le Java 
Runtime par defaut du navigateur par le J RE de Sun. 

Bien entendu la presente invention n'est pas limitee au mode de 
realisation particulier qui vient d'etre decrit mais s'etend a toute 
25 variante conforme a son esprit. 
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REVENDICATIONS 

1. Procede d f acces a un service avec authentication rapide et 
anonymat revocable, caracterise par le fait quMI comprend les etapes 

5 consistant a : 

\X identifier et enregistrer un Client (C) et lui fournir des moyens lui 
permettant de s'authentifier aupres d f une Autorite de Certification 
Anonyme (ACA), 

IQ authentifier le Client aupres de T Autorite de Certification Anonyme 
10 sur la base des moyens fournis en i) et fournir des moyens lui 
permettant de s'authentifier de maniere anonyme aupres d'un Serveur 
(Se), 

iii) authentifier le Client par la production d'une signature anonyme et 
ouvrir et maintenir une session d'authentification anonyme aupr&s d'un 

15 Serveur (Se), et 

iv) permettre selectivement un contact entre le Serveur (Se) et 
TAutorite de Certification Anonyme (ACA) pour lever I'anonymat du 
Client (C) sur la base de la signature fournie a Tetape iii). 

2. Procede selon la revendication 1, caracterise par le fait que 
20 Tetape i) comprend la fourniture de TAutorite de Certification Anonyme 

(ACA), au client (C), de moyens lui permettant de calculer au moins une 
signature anonyme. 

3. Procede selon Tune des revendications 1 ou 2, caracterise par 
le fait que Tetape i) comprend la fourniture d'une Cle Publique (PK), et 

25 d'un Certificat (C). 

4. Procede selon Tune des revendications 1 a 3, caracterise par 
le fait que Tetape i) comprend Tidentification par TAutorite de 
Certification Anonyme (ACA) de la personne physique qui correspond au 
Client (C). 

30 5. Procede selon Tune des revendications 1 a 4, caracterise par 

le fait qu'elle comprend une sauvegarde par TAutorite de Certification 
Anonyme (ACA) de moyens permettant de relier b tout moment le Client 
(C) a n ! importe quelle signature emanant de celui-ci. 
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6. Procede selon Tune des revendications 1 a 5, caracterise par 
le fait qu'il met en oeuvre une cle privee (SK) et une cle publique (PK) 

detenue par le Client. 

7. Procede selon Tune des revendications 1 a 6, caracterise par 
5 le fait que la signature du Client met en oeuvre sa cle privee (SK). 

8. Procede selon Tune des revendications 1 & 7, caracterise par 
le fait que le Client (C) adresse au Serveur (Se) un message contenant 
un jeton (W1000), une signature (S), une cle publique (PK) et un 
Certificat (C). 

10 9 . Procede selon Tune des revendications 1 a 8, caracterise par 

le fait que le Client (C) adresse une cle publique (PK) a I'Autorite (ACA) 
pour I'obtention d'un Certificat (AC). 

10. Procede selon Tune des revendications 1 a 9, caracterise par 
le fait qu'il comprend une etape additionnelle d'echange entre I'Autorite 

15 de Certification Anonyme (ACA) et le Serveur (Se) prealable a I'etape ii) 
par laquelle le Serveur (Se) presente a ladite Autorite (ACA) une requite 
d'obtention de moyens permettant de verifier I'authentification anonyme 

fournie par un Client (C). 

11. Procede selon Tune des revendications 1 a 10, caracterise 

20 par le fait que I'etape ii) comprend trois phases : 

. une premiere phase dans laquelle le Client (C) calcule un ensemble de 
donnees, forme d'une suite de jetons, Tun de ceux-ci permettant 
d'ouvrir une session, tandis que les autres permettent de la maintenir, 
. une deuxieme phase dans laquelle le Client (C) s'engage fortement sur 

25 la suite de jetons apres du Serveur, et 

. une troisieme phase de maintien de la session a I'aide de la suite de 

jetons. 

12. Procede selon la revendication 11, caracterise par le fait que 
la premiere phase est operee par dialogue entre le Client (C) et 

30 I'Autorite de Certification Anonyme (ACA). 

13. Procede selon I'une des revendications 11 a 12, caracterise 
par le fait que les deux premieres phases sont realisees a I'aide d'un 
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navigateur WEB ou d'une application hebergee sur le poste du Client 
(C), forme le cas echeant d'un terminal portable. 

14. Precede selon l'une des revendications 11 a 13, caracterise 
par le fait que la phase de maintien est operee d f un terminal different de 

5 celui utilise pour Touverture de session. 

15. Precede selon Tune des revendications 11 a 14, caracterise 
par le fait que tous les jetons sont a usage unique et fortement 
dependants les uns des autres. 

16. Precede selon Tune des revendications 11 a 15, caracterise 
10 par le fait que I'etape de generation des jetons met en oeuvre deux 

primitives cryptographiques : une fonction de hachage et un nombre 
aleatoire. 

17. Precede selon la revendication 16, caracterise par le fait que ? 
la fonction de hachage H(M) possede les proprietes suivantes : 

15 - H(M) opere sur un message M de longueur arbitraire, 

- le resultat h = H(M) possede une longueur 1 fixe 

- Etant donne M, il est facile a calculer h «. 

- Etant donne M, il est difficile de trouver un autre message M 0 tel que > 
H(M) = H (M 0 ). 

20 18. Precede selon Tune des revendications 16 ou 17, caracterise 

par le fait que la fonction de hachage est choisie dans le groupe 
cornprenant les algorithmes Message Digest 5 ou Secure Hash 
Algorithm. 

19. Precede selon Tune des revendications 16 ou 18, caracterise 
25 par le fait que le premier jeton est obtenu en appliquant la fonction de 

hachage au nombre aleatoire, le deuxieme jeton est obtenu en 
appliquant a nouveau la fonction de hachage au premier jeton obtenu, 
et ainsi de suite pour obtenir n jetons : H(W 0 )=Wi ; H(W u -i)=W n . 

20. Precede selon Tune des revendications 11 a 19, caracterise 
30 par le fait que la deuxieme phase comprend Tobtention d'une signature 

anonyme d'un jeton dMnitialisation W n permettant Tauthentification d'un 
Client par le Serveur. 
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21. Procede selon la revendication 20, caracterise par le fait que 
le Serveur memorise le jeton ^initialisation W u pour permettre la 
verification de la validite de la session. 

22. Procede selon Tune des revendications 11 a 21, caracterise 
5 par le fait que des informations, telles qu'une valeur numeraire, sont 

associees au jeton d'initialisation. 

23. Procede selon Tune des revendications 11 a 22, caracterise 
par le fait qu'a chaque nouvelle authentification le Client (C) transmet 
au Serveur (Se) un jeton de rang inferieur d'au moins une unite a celui 

10 precedemment utilise. 

24. Procede selon Tune des revendications 11 a 23, caracterise 
par le fait qu'apres initialisation le Client (C) transmet au Serveur (Se) 
un jeu W, dont le rang i inferieur est choisi representatif de la valeur 
d'une operation, par exemple du nombre de pas d'une enchere. 

15 25. Procede selon la revendication 24, caracterise par le fait que 

le Serveur (Se) verifie que ^application de la fonction de hachage au 
jeton recu correspond au jeton precedemment utilise. 

26. Procede selon la revendication 25, caracterise par le fait que 
I'etape Hi) comprend la fourniture, par I'Autorite de Certification 

20 Anonyme (ACA), au Serveur (Se), de I'identite physique du Client (C). 

27. Procede selon Tune des revendications 1 a 25, caracterise 
par le fait que I'etape Hi) comprend une prise de contact du Client (C) 
par ladite Autorite pour la fermeture de la session selon un protocole 
controle. 

25 28. Procede selon Tune des revendications 1 a 27, caracterise 

par le fait que le droit de production de signature anonyme a une duree 
de vie limitee. 

29. Procede selon la revendication 28, caracterise par le fait que 
le Client (C) s'identifie aupres de ladite Autorite (ACA) a chaque session. 
30 30. Procede selon Tune des revendications 1 a 29, caracterise 

par le fait que I'Autorite de Certification Anonyme (ACA) est confondue 
avec le Serveur (Se) de sorte que I'identification de maniere forte est 
operee directement aupres du Serveur (Se). 
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31. Procede selon I'une des revendications 1 a 30, caracterise 
par le fait qu'il est applique a des encheres. 

32. Procede selon la. revendication 31, caracterise par le fait que 
le jeton d'initialisation envoye par le Client (C) au Serveur (Se) est 

5- associe aux parametres d'une vente, tels que identifiant de Particle, prix 
et valeur du pas. 

33. Procede selon Tune des revendications 31 ou 32, caracterise 
par le fait que les etapes de surencherissement par le Client (C) sont 
operees par envois successifs de jetons de rang inferieur. 

10 34. Procede selon I'une des revendications 1 a 33, caracterise 

par le fait qu'a I'etape i) I'Autorite (ACA) delivre un Certificat (C) lie a un 
pseudonyme du Client (C) d'une cle publique fournie par le Client et 
elle-tmeme associee a une cle privee gardee secrete par le Client (C). 

35. Procede selon la revendication 34, caracterise par le fait que 
15 le pseudonyme est obtenu par chiffrement d'une donnee liee a I'identite 

du Client. 

36. Procede selon I'une des revendications 34 ou 35, caracterise 
par le fait que le Certificat Anonyme comprend des informations limitant 
la portee du Certificat. 

20 37. Procede selon la revendication 36, caracterise par le fait que 

les informations de limitation sont choisies dans le groupe comprenant : 
I'identifiant d'au moins un Serveur, I'identifiant d'au moins une session, 
une date de validite, une adresse de Client. 

38. Procede selon la revendication 37, caracterise par le fait que 
25 pour ouvrir une session le Client (C) envoie au Serveur (Se) un message 

comprenant un jeton d'initialisation, une cle privee formant signature, 
une cle publique et un Certificat. 

39. Procede selon Tune des revendications 1 a 38, caracterise 
par le fait que I'Autorite (ACA) fournit au Client (C) un Certificat valable 

30 pour plusieurs Serveurs (Se). 

40. Procede selon I'une des revendications 1 a 38, caracterise 
par le fait que I'Autorite (ACA) fournit au Client un Certificat par Serveur 
(Se). 
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41. Procede selon la revendication 40, caracterise par le fait que 
chaque Serveur (Se) foumit un identifiant destine a I'Autorite (ACA). 

42. Procede selon Tune des revendications 1 a 41, caracterise 
par le fait que I'Autorite (ACA) foumit sur requete plusieurs Certificats a 

5 un meme Client (C) destines respectivement a des sites de travail 
different. 

43. Procede selon Tune des revendications 1 a 42, caracterise 
par le fait qu'il met en oeuvre une signature de groupe, par association 
de plusieurs identifiants et cles privees respectives, a une unique cle 

10 publique de groupe. 

44. Procede selon I'une des revendications 1 a 43, caracterise 

par le fait qu'il met en oeuvre une signature aveugle. 

45. Procede selon Tune des revendications 43 et 44, caracterise 
par le fait que les pouvoirs de levee d'anonymat sont repartis entre au 

15 moins deux autorit£s. 

46. Procede selon I'une des revendications 1 a 45, caracterise 
par le fait que I'etape i) comprend la fourniture par I'Autorite de 
Certification Anonyme (ACA), au Client (C), d'un login/mot de passe. 

47. Procede selon I'une des revendications 1 a 45, caracterise 
20 par le fait que I'etape i) comprend la fourniture par I'Autorite de 

Certification Anonyme (ACA), au Client (C), d'un certificat standard. 

48. Procede selon I'une des revendications 1 a 45, caracterise 
par le fait que I'etape i) comprend la fourniture par une Autorite de 
Certification, autre que I'Autorite de Certification Anonyme, au Client 

25 (C), d'un certificat standard. 

49. Procede selon I'une des revendications 1 a 48, caracterise 
par le fait que I'Autorite de Certification Anonyme (ACA) est placee sur 
un serveur d'anonymat (SA). 

50. Procede selon I'une des revendications 1 a 49, caracterise 
30 par le fait que I'Autorite de Certification Anonyme (ACA) est associee a 

un Serveur de Certification (SC). 

51. Systeme apte a permettre I'ouverture et le maintien d'une 
session d'authentification garantissant la non repudiation, caracterise 
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par Ie fait qu'il comprend des moyens adaptes pour la mise en oeuvre de 
trois phases : 

, une premiere phase dans laquelle un Client (C) calcule un ensemble de 
donnees, forme d'une suite de jetons, Pun de ceux-ci permettant 
5 d'ouvrir une session, tandis que les autres permettent de la maintenir, 
. une deuxieme phase dans laquelle le Client s'engage fortement sur la 
suite de jetons apres d'un Serveur (se), et 

. une troisieme phase de maintien de la session a Paide de la suite de 
jetons, 

10 52, Systeme selon la revendication 51, caracterise par le fait 

que la premiere phase est operee par dialogue entre le Client (C) et 
PAutorite de Certification Anonyme (ACA). 

53. Systeme selon Tune des revendications 51 a 52, caracterise 
par le fait que les deux premieres phases sont realisees a Paide d'un 

15 navigateur Web ou d'une application hebergee sur le poste du Client (C), 
forme le cas echeant d'un terminal portable. 

54. Systeme selon Tune des revendications 51 a 53, caracterise 
par le fait que la phase de maintien est operee d'un terminal different de 
celui utilise pour Pouverture de session. 

20 55. Systeme selon Tune des revendications 51 a 54, caracterise 

par le fait que tous les jetons sont a usage unique et fortement 
dependants les uns des autres. 

56. Systeme selon Tune des revendications 51 a 55, caracterise 
par le fait que Petape de generation des jetons met en oeuvre deux 

25 primitives cryptographiques : une fonction de hachage et un nombre 
aleatoire. 

57. Systeme selon ia revendication 56, caracterise par le fait 
que la fonction de hachage H(M) possede les proprietes suivantes : 

- H(M) opere sur un message M de longueur arbitraire, 
30 - le r^sultat h = H(M) possede une longueur 1 fixe 

- Etant donne M, il est facile a calculer h 

- Etant donne M, il est difficile de trouver un autre message M 0 tel que 
H(M) = H (M 0 ). 
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58. Systeme selon Tune des revendications 56 ou 57, 
caracterise par le fait que la fonction de hachage est choisie dans le 
groupe comprenant les algorithmes Message Digest 5 ou Secure Hash 
Algorithm. 

5 59. Systeme selon Tune des revendications 56 ou 58, 

caracterise par le fait que le premier jeton est obtenu en appliquant la 
fonction de hachage au nombre aleatoire, le deuxieme jeton est obtenu 
en appliquant a nouveau la fonction de hachage au premier jeton 
obtenu, et ainsi de suite pour obtenir n jetons : H(W 0 )=W 1 ; H(W U . 

10 0=W n . 

60. Systeme selon Tune des revendications 51 a 59, caracterise 
par le fait que la deuxieme phase comprend I'obtention d'une signature 
anonyme d'un jeton d'initialisation W n permettant ^authentication d'un 

Client par le Serveur. 
15 61. Systeme selon la revendication 60, caracterise par le fait 

que le Serveur memorise le jeton d'initialisation W u pour permettre la 
verification de la validite de la session. 

62. Systeme selon Tune des revendications 51 a 61, caracterise 
par le fait que des informations, telles qu'une valeur numeraire, sont 

20 associees au jeton d'initialisation. 

63. Systeme selon I'une des revendications 51 a 62, caracterise 
par le fait qu'a chaque nouvelle authentication le Client (C) transmet 
au Serveur (Se) un jeton de rang inferieur d'au moins une unite a celui 

precedemment utilise. 

25 64. Systeme selon l'une des revendications 51 a 63, caracterise 

par le fait qu'apres initialisation le Client (C) transmet au Serveur (Se) 
un jeu W, dont le rang i inferieur est choisi representatif de la valeur 
d'une operation, par exemple du nombre de pas d'une enchere. 

65. Systeme selon la revendication 64, caracterise par le fait 

30 que le Serveur (Se) verifie que ['application de la fonction de hachage au 
jeton recu correspond au jeton precedemment utilise. 
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66. Systeme selon Tune des revendications 51 a 65, caracterise 
par le fait que lesdits moyens mettent en ceuvre les etapes consistant a 

ii identifier et enregistrer un Client (C) et lui fournir des moyehs lui 
5 permettant de s'authentifier aupres d'une Autorite de Certification 
Anonyme (ACA), 

10 authentifier le Client aupres de I' Autorite de Certification Anonyme 
sur la base des moyens fournis en i) et fournir des moyens lui 
permettant de s'authentifier de maniere anonyme aupres d'un Serveur 
10 (Se), 

iii) authentifier le Client par la production d'une signature anonyme et 
ouvrir et malntenir une session d'authentification anonyme aupres d'un 
Serveur (Se), et % 

iv) permettre s^Iectivement un contact entre le Serveur (Se) et V; 
15 P Autorite de Certification Anonyme (ACA) pour lever I'anonymat du . 

Client (C) sur la base de la signature fournie a Petape iii). & 

67. Systeme selon Tune des revendications 51 a 66, caracterise > 
par le fait qu'il est applique a des encheres. 

68. Systeme selon la revendication 67, caracterise par le fait ' v 
20 que le jeton d'initialisation envoye par le Client (C) au Serveur (Se) est 

associe aux parametres d'une vente, tels que identifiant de Particle, prix 
et valeur du pas. 

69. Systeme selon Pune des revendications 67 ou 68, 
caracterise par le fait que les etapes de surencherissement par le Client 

25 (C) sont operees par envois successifs de jetons de rang inferieur. 

70. Systeme selon Pune des revendications 51 a 69, caracterise 
par le fait que lesdits moyens mettent en oeuvre un message adresse 
par le Client (C) au Serveur (Se), pour ouvrir une session, comprenant 
un jeton d'initialisation, une cle privee formant signature, une cle 

30 publique et un Certificat. 

71m Systeme selon Pune des revendications 51 a 70, caracterise 
par le fait que lesdits moyens mettent en oeuvre un certificat anonyme. 
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72. Systeme selon I'une des revendications 51 a 70, caracterise 
par le fait qull met en oeuvre une signature de groupe, par association 
de plusieurs identifiants et des privees respectives, a une unique cle 

publique de groupe. 
5 73. Systeme selon Tune des revendications 51 a 70, caracterise 

par le fait qu'll met en oeuvre une signature aveugle. 

74. Systeme selon I'une des revendications 51 et 73, caracterise 
par le fait que les pouvoirs de levee d'anonymat sont repartis entre au 

moins deux autorites. 
10 75. Systeme selon I'une des revendications 51 a 74, caracterise 

par le fait que I'etape i) cornprend la fourniture par I'Autorite de 
Certification Anonyme (ACA), au Client (C), d'un login/mot de passe. 

76. Systeme selon Tune des revendications 51 a 75, caracterise 
par le fait que I'etape i) cornprend la fourniture par I'Autorite de. 

15 Certification Anonyme (ACA), au Client (C), d'un certificat standard. 

77. Systeme selon I'une des revendications 51 a 76, caracterise 
par le fait que I'etape i) cornprend la fourniture par une Autorite de 
Certification, autre que I'Autorite de Certification Anonyme, au Client 
(C), d'un certificat standard. 

20 
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